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Abstract — Originator Control allows information providers to define the information re-dissemination condition. Combined with usage 
control policy, fine-grained 'downstream usage control' can be achieved, which specifies what attributes the downstream consumers 
should have and how data is used. This paper discusses originator usage control, paying particular attention to enterprise-level dynamic 
business federations. Rather than 'pre-defining' the information re-dissemination paths, our business process slicing method 'capture' 
the asset derivation pattern, allowing to maintain originators' policies during the full lifecycle of assets in a collaborative context. 
First, we propose Service Call Graph (SCO), based on extending the System Dependency Graph, to describe dependencies among 
partners. When SCG (and corresponding 'service call tuple' list) is built for a business process, it is analyzed to group partners into 
sub-contexts, according to their dependency relations. Originator usage control can be achieved focusing on each sub-context, by 
examining downstream consumers' security profiles with upstream asset providers' policies. Second, for analyzing SCG, we propose 
two 'slicing' strategies, namely 'asset-based' and 'request-based' slicing, to deal with the scenarios of both 'pre-processing' a business 
process scripts and 'on-the-fly' analyzing service compositions. Last, our implementation work involves a 'context manager' service for 
processing business processes defined in WS-BPEL. It can be composed with our former proposed policy negotiation and aggregation 
services to provide policy-based end-to-end security management. We also make experiments based on processing the sample 
processes that come with 'WS-BPEL2.0' specification. 
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1 INTRODUCTION 

In collaborative systems, participants share digital as- 
sets, including computing capability (e.g. Web Service) 
and information (e.g. data), in order to produce a fi- 
nal artifacts (e.g. composed service, new information 
generated from data aggregation). As assets are shared 
beyond ownership boundary, risk of Intellectual Prop- 
erty infringement (e.g. circumventing of trade secret, 
or even leakage to a competitor) associated to 'loss of 
governance' is the major barrier for moving toward 
collaborative business model [ 13 J I.11J [4J . There security 
requirement is brought to an end-to-end scale: to ensure 
the protection of corporate patrimony value during it full 
lifecycle in the collaborative business process, covering 
the creation, derivation and destruction stages, paying 
particular attention on how the asset is used by part- 
ners. Overcoming this barrier relies on a comprehensive 
method that can make the 'pre-decision' about selecting 
partners based on historical comportment, as well as can 
continuously regulate the partners behaviors on the fly 
in the collaborative business process. 

Such requirement leads to the pursuit of Originator 
Control (ORCON) with Usage control policies [18J (or 
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Downstream Usage control [2J), where the goal is to 
require recipients to gain originator's approval for re- 
dissemination an originally digital asset or a new digital 
asset that includes it [18J. Recent progresses in 'usage 
control' policies [16J [12J |30J pave the bedrock for fine- 
grained control of 'due usage' actions and 'obligations' 
on digital assets. For now a stage. Originator Usage 
Control policies are mainly built around the strategy of 
close-coupling the control of assets dissemination paths 
and the control of 'due usage' in each hop |2| [18|. 
This strategy suit well scenarios where providers want 
to have direct control on the exact dissemination steps. 
But whan applied to more general business federation 
scenarios, the close-coupling strategy can be cumbrous. 
For now, collaborative business processes are achieved 
mainly by 'on-the-fly' service composition or pre-defined 
orchestration (e.g. with WS-BPEL). In either case, the 
originator's end-to-end security requirements concern 
choosing the partners that possess eligible 'Quality-of- 
protections' for its asset. Once the originators' security 
criteria are met, the decision of choosing which partners 
(i.e. the exact paths of asset dissemination) is more 
related to the business logic. Then, in the perspective 
of security engineering for the collaborative context as a 
whole, ensuring that all the providers' security criteria 
are maintained during the full lifecycle of their assets, 
is the essence. This involves analyzing the collaborative 
business process to track the dissemination paths of 
every asset, the co-effect of their providers' policies 
calculated when assets merge, the consumer's security 
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profile (and 'usage' activities) checked when an assets is 
consumed. 

In former works we have proposed a collaborative 
usage control model that deduces the co-effect of poli- 
cies 1 25 J and an implementation architecture supporting 
'usage control' enforcement [27 1. It's our intention in this 
paper to complete our end-to-end security management 
framework, by developing a method for analyzing com- 
plex collaborative context and applying collaborative 
usage policy to manage asset sharing activities. The 
basic thought is that security foundation for a successful 
collaborative process is that each originator's policy is 
fulfilled during the whole business process. 

For holistic view, we briefly introduce our analysis 
of the asset derivation patterns and sub-context modes 
involved in collaborative business processes. Security 
management can be done in the scope of each 'sub- 
context'. 

The first contribution of this paper is a 'Service Call 
Graph' (SCG) we developed based on modifying and 
extending System Dependency Graph (SDG), for repre- 
senting partners' interactions in collaborative business 
processes. We also propose a data structure 'service call 
tuple' corresponding to the SCG for capturing 'depen- 
dencies' among partners. 

Then We propose 'asset-based' and 'request-based' 
context slicing methods, for mining the 'asset (RoP) 
aggregation' and 'request (QoP) aggregation' from the 
'service call tuple' list that represents a business pro- 
cess. Such aggregations decides the partitions of sub- 
contexts, where collaborative usage control policies can 
be applied. 

We analyze the sub-context developments, using 'pre- 
processing' and 'on-the-fly processing' strategies, and 
describe how originator usage control is achieved by 
managing sub-context developments. 

We also implement a 'context manager' service for 
the context slicing task, paying particular attention to 
complex business process defined in WS-BPEL. This 
service can be deployed with other components of our 
'collaborative usage control policy' enforcement system 
[], to provide originator usage control service. Experi- 
ment results of processing the sample business processes 
that come with 'WS-BPEL2.0 specification' are presented. 

Section (|2) introduces the 'usage control' model we use 
as foundation for ORCON, and the Service Dependency 
Graph (SDG), based on which we develop a business 
process 'slicing' method. The difference between our 
approach and several representative ORCON works are 
discussed. Section I l2.3b gives a general level description 
of the assets aggregation patterns usually involved in a 
business process. Section (|3) introduces the business pro- 
cess analysis method, led by a motivating use case. Sec- 
tion lHJI discusses the capability of our analysis method 
with a more comprehensive use case. Implementation 
and experiment results are introduced in section (|5]l. 



2 Background and related works 

Originator Control (ORCON) aims at enforcing 
providers' policies during the full lifecycle of assets 
put to a collaborative context. Combining with 'usage 
control' policies enhance its expressivity w.r.t. defining 
the 'consumption activities' and the access condition. 

2.1 Originator control (ORCON) 

ORCON was brought forward to restrict the distribution 
of documents in paper world |5|, where the approval 
of originator is always required. Traditional ORCON 
solutions in cyberspace aim at automate ORCON [211 
[|14||, using some form of non-discretionary access control 
list fl8 l. Recent works combine ORCON with usage 
control, greatly enhanced its expressivity flSlI |2J. But 
these works center on allowing originators to control the 
exact path their asset are re-distributed, therefore is more 
related to the 'information dissemination' control, which 
are mostly encountered in security research of social net- 
work or pub/sub systems. Whereas in enterprise level 
federations, the assets dissemination path is more closely 
related to the business logic. In other words, the origi- 
nators' security concern is that their assets must only 
be passed to partners with eligible security attributes 
(encrypted communication channel, secured platform, 
organizational security management convention, etc.) 
and allowed 'usage' activities. As soon as these criteria is 
met, the exact chosen partners and asset sharing 'paths' 
are decided mainly according to 'common business goal' 
(e.g. functional requirements and QoS requirement in 
Web Service composition). Our work focuses on the en- 
terprise level business federation scenarios and therefore 
is different from the former originator usage control 
works in that we identify the partners that the originator 
will share assets with, allowing to exam their security 
profiles with the originator's requirements, based on 
collaborative usage control policies. 

2.2 Collaborative usage control policy 

A basic usage control policy model can be described by 
the following factors: 



UCON = (S", O, Ct, Rt, Ob, Rn, P) 



(1) 



where 

• 'S' (Subject) is the party that can get a Right on the 
asset. It is specified by a set of 'Subject Attributes' 
{SAT). 

• 'O' (Object) is the asset to be protected by the policy 
rule. It is specified by a set of 'Object Attributes' 
{OAT). 

• 'Ct' (Context) is the collaboration context that is 
associated to the status of the system infrastructure, 
the environment and the business federation. It is 
specified by the set of 'Context Attribute'(CiVAr) 

« 'Rt' (Right) is the Operation upon the asset defined 
by 'Sh' that the Subject is allowed to achieve. 
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• 'Ob' (Obligation) is the obligation that must be 
fulfilled by the Subject when it gets the Right. 

• 'Rn' (Restriction) is the attribute (from 'Context' set) 
associated to 'Rt' or 'Ob' to further confine in what 
circumstance they are carried out. 

• 'P' (Policy)is the usage control policy definition. It 
maps predicates on a set of attributes identifying 
'Subject', 'Object', 'Context' to the predicates on a 
set of attributes identifying 'Right' or 'Obligation'. 

Some works lay the foundation of 'usage control' 
system. In the UCONabc model HSOj (19| [29], access 
decision is based on not only role (as in RBAC) or 
identity (as in MAC and DAC), but on diverse attributes 
of subjects and objects. With the grant and exertion 
of a 'usage' right, multiple consumption actions (e.g. 
playing several songs) can happen, during this process, 
the attributes of the object (e.g. the amount of the 
'not used' objects) and subject (e.g. balance in her/his 
account) are constantly changing. The authors defined 
models for 'attribute-update' actions, which capture the 
semantic of this process. A formalization dedicated to the 
UCONabc niodel has been introduced Ull ||32| using 
Lamport's Temporal Logic of Action (TLA). It describes 
the temporal constrain between the action in Authoriza- 
tion (granting of right). Obligation and attribute update 
that results from the exercising of granted rights or 
imposed obligations. Manuel Hilty et al. proposed a 
usage control policy language [8J based on the analysis 
of usage control requirements and existing control mech- 
anisms [9 J [20]. Their work gave a taxonomy on usage 
actions, as well as the common attributes of subject, ob- 
ject and environment, e.g. time, cardinality ('how many 
times' an action can be performed), events, purpose of 
usage, etc. 

In collaborative context, when assets merge, their 
providers' policies should also aggregate, to achieve 
ORCON. One fundamental issue is to set the aggregation 
method so that the resulting policy correctly interprets 
the original goal of the providers' policies. In our former 
work 1 25 1, we built a collaborative usage control scheme 
by introducing several factors: 

• 'Sh' (Stakeholder) is the owner of the rule, and is 
the owner or co_owner of the assets related to the 
rule. 

• 'Ic (Lifecycle) defines the lifecycle [23] of a predi- 
cate, extending the effect of the predicate to (indi- 
rect) partners corelated by the business federation, 
e.g. predicates tagged with Ic = dp take effect 
only between 'direct partner', effects of predicates 
tagged with Ic = eot are maintained till the 'end of 
transaction'. 

• 'G' (Aggregation algorithm) is the algorithm used to 
'combine' the individual policies from each 'Sake- 
holder'. 

Our policy scheme follows such design pattern that 
providers use 'RoP' policies to express their 'require- 
ments of protection' upon their assets. Consumers use 



QoP (analogous to the P3P [[28] approach) to express 
their 'Quality of Protection', e.g. 'promises' about the 
protection they offer (they way they consume asset, 
their security attributes, etc.). When two assets merge, 
policies (the RoPs that are refined with 'Ic') upon them 
are aggregated. For the partners who will consumer 
the same set of assets, their QoPs are aggregated. The 
aggregation algorithm detect potential conflicts between 
the policies that will merge, in order to find inconsis- 
tent security attributes (between QoPs) or requirements 
(between RoPs). 

In short, this policy use a strategy similar to the 
'stick policy' method flSl (3| |[TJ, to allow propagating 
providers policies to the artifact of collaborative context, 
when their assets are merged into it. The advantage of 
using scheme to manage collaborative context security 
is that security configuration can be done in a peer-to- 
peer manner: if every partners' security requirements are 
met, the condition (in security perspective) for context 
to be set is fulfilled. But for this, partners' assets sharing 
relations should be identified. For a holistic view, next 
section briefly introduces our former work on analysis 
of the sub-context modes [26| incurred by asset sharing 
activities. 

2.3 Sub-context modes 

Basically, only partners corelated by (both direct or in- 
direct) assets exchanging a deemed in on sub-context. 
For convenience of discussion, we denote the assets 
provided by partners as 'Original Assets' ('O-Assets' for 
short) and the artifacts of collaborative work (aggre- 
gating several O-Assets) as 'Collaboration Assets' ('C- 
Assets' for short). 

Security management with the asset aggregation view- 
point are based on the following principles: 

1. All participants having the same 'Rights' upon the 
same C-Asset(s) are gathered in one sub-context. 

2. Each sub-context has its Context Security Policy 
('CSP' for short), which has two parts: RoPcsp 
includes the providers' RoPs and represents the 
providers' security requirements on the C-Asset; 
QoPcsp includes the consumers' QoPs and rep- 
resents the the sub-context's security profile for 
future assets providers. 

3. A participant can belong to more than one sub- 
context at the same time. It must follow the CSPs 
of all the sub-contexts it belongs to. 

The central issue is to analyze the provider-consumer 
relation among partners. Note that a participant in the 
collaborative context can act as both provider and con- 
sumer, according to the business logic, which make the 
analysis tricky. We use a sample supply chain scenario 
(see figure |l]l to presents the sub-context modes one can 
encounter when analyze a collaborative context. 

We see 4 basic sub-context partition modes. 

• 'Each Asset One Group (EAOG)' mode: 
When all providers can distinguish their own asset 
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EAOG: Ia...IO«,I SASG: C0a...C0n.C4 

SAMG: C0a...C0H,C5 MAMG: C0a...C0n,Cl,C2,C3 

Fig. 1 . Sub-contexts patterns in business federation 



(O-Assets) in the artifact of business collaboration 
(C-Asset), there is no asset aggregation, each part- 
ners works in a separate sub-context. An example 
(see 'EAOG'in [U is when a down-stream provider 
(D) receives inventory information '/„.../„' from up- 
stream providers (UP) and concatenates them in one 
XML file '/', each of them as a separate node. The 
manufacturer (M) reading one nodes must follow 
the due policy of UP. 

• 'Single-Asset Single-Group (SASG)' mode: 

If the O-Assets in C-Asset are not identifiable, 
their providers are deemed as in one single group, 
given that they define the same rights. An example 
(see 'SASG'in [T]| is when production information 
'Coa--Con' are merged by 'D' to generate a global 
scheduling 'C4'. 'M' reads must fulfill the policies 
of all the 'UPs' in order to read C4. 

• 'Single-Asset Multi-Group (SAMG)' mode: 

If the O-Assets in C-Asset are not identifiable, by 
their providers have define multiple rights, each 
right forms a group. 

An example (see 'SAMG'in[lJ is when the 'UPs' all 
define multiple rights (e.g. 'read' and 'disseminate'). 
Then their policies co-define multiple rights on C5 
has multiple rights. Consumers holding different 
Rights upon the same C5 are deemed as in different 
sub-contexts. 

• 'Multi-Asset Multi-Group (MAMG)'mode: 

If there are multiple C-Assets and an O-Asset can 
belong to more than one C-Asset at the same time. 
We should identify which O-Assets disseminate in 
which C-Assets, in order to examine, firstly, whether 
the providers' policies of aggregated assets are com- 
patible and, secondly, whether the security profiles 
of the consumers for a C-Asset fulfill the policies 
(coming from the policies of O-Assets providers) on 
that C-Asset. 

These 4 patterns generally exist in many collabora- 
tive contexts, as long as the issue of information asset 
protection and consumption exists. Imagining changing 
above supply chain scenario to others, e.g. switching 
the materials providers as Cloud providers or Service 
providers, the asset exchange pattern still fall in the 4 



modes. 

The CSP aggregation process involves detecting po- 
tential conflicts, with a algorithm we proposed before 

The center issue in this paper is to develop a method 
that analyzes the collaborative business process to parti- 
tion sub-contexts and allocate partners according to asset 
sharing patterns. We develop a method for this task, bor- 
rowing (and modifying) the method used for programm 
slicing with System Dependency Graph (SDG). 

2.4 System dependency graph 

In business federation, assets transfer across organization 
boundaries, possibly merging with other assets. In order 
to give a life long protection to an asset, it's necessary to 
capture the asset derivation relations and track the asset 
in the artifacts of business process. This issue is similar 
in its nature to the 'Program Slicing' (6l l33ll task based 
on System Dependency Graph (SDG) 16] [7J. Program 
slicing asks about which statements influence (backward 
slice), or is influenced by (forward slice), the current 
statement under exam. Whereas collaborative process 
analysis asks about which processes (functionalities pro- 
vided by a partner can be seen as a process, e.g. imple- 
mented with a Web Service) influence which processes, 
therefore tracing asset exchange and derivations. 

We use a similar approach to 'slice' a collaborative 
context into 'sub-contexts'. Each 'sub-context' confine a 
scope of partners interrelated by assets exchanges (in 
other words, partners in different 'sub-context' don't 
exchange asset, although they are in the same collab- 
orative process). We firstly give an overview of the 
'sub-context' modes we may encounter when analyzing 
a collaborative context, before introducing the analysis 
method. 

In the following sections, we fist discuss the analysis 
of a collaborative context with SASG mode, guided by a 
simple use case, in order to introduce the basic thoughts 
underlaying out analysis method. Then we use a full- 
fledged use case to describe how our method is used to 
deal with complex business process that is in MAMG 
mode. 



3 Context analysis based on 'context 

SLICING' 

We use a simple use case (see figure EJ of Web Service 
composition to facilitate our discussions. 




^1 (ml-e; 



Fig. 2. Service composition represented witin SCG 
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Use case 1: An assurance association 'Deirect as- 
sure'(D) consults 'medical information' (m) from 'Bone- 
tat clinique'(B). Part of the information, 'cardiac exam' 
(e), is taken from a medical examination laboratory 
'Cardis health'(C). The business process includes the 
following steps: 

(1) D contacts B, requiring m; 

(2) B contacts C, requiring e, in order to reply D, if 
success, 

(3) C sends e to B; 

(4) B merges e with m; if success, 

(5) B answers to D. 

As B and C are asset (information) providers in this 
use case , ORCON means that their policies should be 
respected during the whole lifecycle of their assets. This 
involves answering two questions: 

• (1) Which partners will access an asset? A question 
of this type for 'use case 1' is "The 'Cardiac exam 
info' provided by C will be accessed by B or D, or 
both of them?" 

• (2) Which assets will be accessed a party? As a 
simple illustration, in 'use case 1' a question of this 
type is "Whether D will access the assets provided 
by B and C, either directly or indirectly". 

While both of these questions can be answered intu- 
itionally for 'use case 1', the pondering procedure reflects 
the goal and method of context slicing. Question (1) is 
related to QoP aggregation among partners. Question 
(2) is linked to RoP aggregation. The goal is to enable 
the 'down-stream usage control' [2], so that indirect 
consumers should follow the policies of the O-Assets 
involved in the C-Asset they access. The method we use 
is analogous to the 'Program Slicing' fS] f331 based on 
System Dependency Graph (SDG) [6J |7J. 

3.1 Service call graph 

A participant in a collaborative contexts is analogous 
to a 'procedures' in a SDG: receives calling information 
and produce results. We use Pi i — P, to denote that 
a party Pi depends on another party Pj with 'control 
dependency': whether Pi will be activated depends on 

Pj. Pi < — Pj denotes that a party Pi depends on 
another party Pj with 'data dependency': data provided 
by Pj are involved in data produced by Pi. We propose 
a data structure 'Service Call Graph' (SCG) based on 
extensions of SDG to represent partner interactions in the 
collaboration context. These extensions can be illustrated 
with 'use case 1' (figure |2] is a SCG of 'use case 1'): 

• The fist extension is that 'data dependency' in our 
SCG is differentiated as two types: an 'aggregation 
dependency' means Pi involves data of Pj (the same 
as SDG), a 'non-aggregation dependency' denoting 
that data produced by Pi does not involve data 
from Pj (an extension of SDG). For example, in the 
SCG presented in figure l|2ll, the blue edges (step 
1 and 2) represent 'control dependency' . The green 



edges (steps 3, 4 and 5) represent 'data dependency' , 
where The solid green lines (edge 4 and 5) means 
that the output data (response) includes information 
from the input data (aggregation dependency). The 
dashed green line (edge 3) means that the output 
data does not include information from the input 
data (non-aggregation dependency). 

• The second extension is that the assets carried by 
the message exchanges are attached directly to the 
edges in SCG (see edges 3, 4 and 5 in figure |2ll. 

• The last extension is that we represent /ai/ed inter- 
actions (due to negative result of policy negotiation) 
with dashed blue lines. A more comprehensive use 
case presented in section |4] will give such examples. 

In order to capture assets derivation pattern, we define 
'indirect dependency', based on partner service call in 
a business collaboration: VP^ , Pj , P/j , Va e {c,d} where 
Pi, Pj and Pfe are partners in a collaboration, c and d 
are 'control dependency' and 'data dependency' rela- 
tions respectively, Pj is 'indirectly dependent' on Pfe, if 
'P, ^ P, A P, ^ Pfe'. 

There are two types of indirect dependency. 'Indirect 
data dependency' is the situation where each relation in 
a dependency chain is 'data dependency'. We sum it up 
as an axiom: 

Axiom 1 (Indirect data dependency): 'iPi,Pj, P^: Pj < — 

P, A P, ^Pk^P^^Pk 

For example, in 'use case 1', whether D gets the results 
or not depends on the response of B. B's response in turn 
depends on response from C. 

'Indirect control dependency' is the situation where 
'control dependency' relation exists in the dependency 
chain: 

Axiom 1 (Indirect control dependency): 'iPi , Pj ,Pk,\/a e 
{c,d}: (P, ^ P,- A P, ^ P,) V (P, ^ P, A P, ^ 



P, 



Pfc 



,;-P.^^fe 

As an example for indirect control dependency, in 'use 
case r, whether C will be called depends on B. Whether 
B will be called in turn depends on D. So C is indirectly 
control dependent on D. 

We can see the slight difference between axiom [T] and 
axiom |2l Data dependency is transitive only when the 
edges in the dependency chain are all associated to 
'data dependency', whereas when control dependency 
exists in a dependency chain, it propagates 'control 
dependency' to the chain. 

When analyzing complex business process, e.g. those 
defined by WS-BPEL, one must consider the impact of 
'variables', which are used to carry information inside 
the process. As information carried by 'variables' are 
eventually exchanged between partners, the information 
exchanges between 'variables' (e.g. through 'value as- 
signment') also lead to assets derivation. 

These variables can be complex data type (e.g. defined 
by XML schema). In this case, if a part of a variable is 
valued-assigned to a part of another variable (see the 
'sample process' in WS-BPEL specification (13), the later 
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variable is 'data dependent' on the former one. Thus we 
have the following axiom: 

Axiom 3 (Direct data dependency between variables): 

" Cjn ^ ^i J Cji t ij f Cra ^ Cji =?> r^ i ij 

where Pi and Pj stand for 'variables', 'c,,/ is part of P,;. 
'c„' is part of Pj. 

There are only 'data dependency' relations between 
variables, as the only form of interactions between vari- 
able is data exchange. Therefore the conditions leading 
to 'indirect data dependency' between variables can be 
described by axiom [T] In the following discussion about 
dependency relation, we don't need to differentiate 'vari- 
ables' from 'partners', as we can see that dependency re- 
lations for 'partners' and for 'variables' can be described 
by the same set of axioms. 



3.2 Service call tuple 

We use a tuple < Pi ^— > Pj,A > to denote the service 
call from Pi to Pj, A being the exchanged asset. We can 
have the following basic types of service call tuple: 



< P^ 



Pi > denotes that P; calls P, with 



message carrying no asset. 
• < Pi < — Pj > denotes that Pi receives a message 
from Pj that carries no asset. 

An example of these two types of service call is 
when a mail agent queries a mail service for whether 
a mail is sent, and receives confirmation from the 
server. In such case the call message and the re- 
sponse message are deemed as not carrying any 
asset (i.e. information needing protection). We can 
see that whether a message carries asset or not 
depends on the straining criteria of security in a 
specific application context. 

. < Pj — > Pj:Ai > denotes that Pj calls Pj, by 
sending asset A;. 

» < Pi < — Pj , Ac > denotes that Pi receives a 
response from P, that carries asset A,,. 

. < Pi ^^ P,-,Aj,Ao > denotes that P, calls Pj, 
sending asset A^ and receiving response carrying 
asset Ao, where Aq includes information from A;. 

. < P., ^A^ Pj,A„Ao,<^> denotes that P^ calls P,, 
sending asset A^ and receiving response carrying 
asset Ao, where Ao does not include information 
from Ai. 

» < Pi < — > Pj,(^> denotes that the interaction be- 
tween Pi and Pj failed, due to negative result of 
poHcy negotiation. 
These tuples represent the edges of SCG. We can 
see that asset exchanges (and aggregations) occur with 
service calls. 

3.3 Assets aggregation 

Usually, with partners' interactions, assets derivations 
(basically, either 'merging' or 'splitting') happen. There- 
fore, recognizing assets derivation relations involves 



firstly formalizing partner interactions with service call 
tuples. Then the service call tuples list can be analyzed 
to track the asset 'merging' or 'splitting' activities. There 
are three situations that may incur such activities: 

m li X sends information containing asset value to 
Y, who aggregates it with its own information 
(expressed as Y calling itself) and further send it 
to Z. In this situation, we can identify the follow 
service call tuple sequence: 



<X 
<Y 
<Y 



■Y,Ax> 
>Y,Ax,Ay> 
Z,Ay > 



(2) 



• If X sends information within its request to Y and 
gets response(s) from Y that includes X's infor- 
mation. This situation is represented by the follow 
service call tuple: 



<X 



Y,Ax,Ay> 



(3) 



Extra attentions should be paid in this case, as we 
can not be sure that the response message includes 
information from the request message. Whether the 
output (responses) from a partner integrates the 
input (request) or not depends on the business logic 
of this partner's system. An example of this case 
is when X sends some personal information to Y 
to calculate the insurance premium. If the response 
from Y consists in the insurance premium and the 
person's information, there is an assets derivation, 
otherwise if Y answers with only the insurance pre- 
mium, there is no assets derivation. Deciding what 
information includes 'asset value' and should be 
protected is closely related to application domain. In 
any case, we need to know relations between inputs 
and outputs to conclude if assets derivation exists 
during a direct interaction. This can be done by an- 
alyzing partner's service functional description, e.g. 
WSDL in a Web Service context. It can also be done 
at the business process level, by letting the service 
composition service to adding extra indicators to a 
WS-BPEL script. In the modeling level, we use the 
following notations to define whether the partner 
response includes information from request or not: 
- Most of the time, request information (or part 
of it) is included in the response, therefore we 
use the default tuple to represent it: 



<Y 



r,A,,Ao> 



(4) 



- Whereas '5^' is used to indicate that no informa- 
tion of the request is included in the response: 



<Y 



Y,X,Ao,<t> 



(5) 



If X 'fetches' (expressed by 'stackrelc — >', as there 
is no asset value in the request) information from Y 
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and aggregates its own information with it: 
<X ^Y > 



<X 
<X 



>X,Ay,Ax > 



(6) 



As an example, we build the list of service call tuples 
for 'use case 1' (See formula [71 where the tuples in the 
list are indexed by the steps of business process): 



<t1,D 
<t2,B 
<t3,B 

<t4:,B ^ 

< t5,D 



B> 
C> 

C,' E' > 

> B,' E',' ME' > 
B,' ME' > 



(7) 



The assets derivation relations between partners are 
equivalent to data dependency relations between them. 
Therefore assets derivation trail, which decides the sub- 
context pattern, can be mined from the list of service call 
tuples. 

3.4 Sub-context slicing 

Like the information reachability questions in SDG, the 
assets derivation trail can be tracked by scanning the 
service call tuples list, paying particular attention to 
asset aggregation. Based on this, providers' policies upon 
assets can be maintained during assets derivations. This 
involves, firstly, allocating corelated assets in the same 
sub-contexts. 

We use a data structure 'context development tuple' 
< Nc, Vc,Pc,La, Lp, Sc > to record the information of 
sub-context development, where: 

• Nc is the name of the sub-context. 

• Vc is its version. 

• Pc the parent sub-context. 

• La a list of all the asset involved in the sub-context. 

• Lp the collection of policies in the sub context. 

• Sc the step of business process. 

This tuple is built by the sub-context slicing process 
which scans the SCG (e.g. service call tuple list) according 
two strategies: 'asset-based slicing' and 'request-based 
slicing'. 

Asset-based slicing focuses on capturing the aggre- 
gation relation among assets. Using this method, a sub- 
context is created when the first O-Asset is launched 
into the collaborative context by the owner. When a new 
partner join the context with a new O-Asset, the sub- 
context consisting of the existing asset is updated, if 
the new partner's O-Asset is merged with the existing 
C-Asset. Otherwise (i.e. the new partner's O-Asset is 
not merged with existing C-Asset), a new sub-context 
is created. In 'use case 1', the list of sub-context tuples 
is as follows: 



<i?cs,l,(0),(e),(i?oPc),T3> 

< RcB,2, (< RcB-1), (e, to), {RoPc, RoPb), t4 > (8) 

< i?cB, 3, (< RcB-2), (e, to), {RoPc, RoPb), t5 > 

We can see that in step 3 (represented by r3), the first 
sub-context is created, including the asset E and the 
RoPc on it. We name the context after the interaction 
leading to the creation of it, e.g. Rcb ('resource' sending 
from C to B). Its version is '1'. It has no parent context 
{(j)). Then in step 4, as new asset M merge with E, the 
sub-context Rcb-^ is updated to Rcb-"^- And in step 5, 
it stays unchanged. 

This list describes the evolution of the sub-contexts. 
There is only one sub-context for 'use case 1', which can 
be represented with an assets derivation diagram (see 
figure |3]l. 



e -3^ 



m 



-4-> 



me-^^me 



Fig. 3. Assets derivation in tine sample use case 

Using the 'asset-based slicing' method, policy nego- 
tiation and aggregation (including conflicts detection) 
can not be done until the first asset launched into the 
context ('step 4' of use case 1). If there is conflict, steps 
t2 and t3 are actually wastes of partners' resources and 
don't need to be proceeded. Therefore the 'asset-based 
slicing' method is better to be used for 'pre-processing' a 
business process script (e.g. WS-BPEL documents) before 
the execution of it. To analyze a collaborative context 'on- 
the-fly', we need a 'request-based slicing' method. 

Request-based slicing creates a sub-context when the 
first request is made. Then when a new partner joins 
the business process, its QoP can either be aggregated 
into existing sub-context, or lead to the creation of a 
new sub-context. The decision is also straight forward: 
the QoPs of two partners should be aggregated, if 
they will access the same asset in future steps of the 
collaboration context. With this method, we have the 
following list of sub-context tuples for 'use case 1': 



< QDB,lA<t>)AQoPD),Tl > 

< Qdb,2, [Qdb-I), {QoPd,QoPb),t2 > 



(9) 



This tuple list captures QoP aggregations. When the 
first request is made by D in step 1, a sub-context is 
created, including the QoP of D. We name the context 
after the interaction leading to the creation of it, e.g. 
Qdb ('query' sending from D to B). In step 2, as B is 
requesting assets from C 'on behalf of D, QoPb and 
QoPc are aggregated. Therefore sub-context Qdb-^ is 
updated to Qdb ■'2. 

However, deciding who will access the same asset 
is more tricky than it may firstly look like, especially 
when partners work asynchronously, (e.g. between that 
a partner 'X' receives request from partner 'Y' and 
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responds Y, another partner 'Z' sends request to X). We 
provide basic protocols for dealing with such cases: 

• Protocol 1: After X receiving request from Y, all 
requests that X sends to other partners are deemed as on 
behalf of Y , until X responds Y, or X receives a request 
from another partner Z. This involves that a request 
from Y to X establishes a 'on behalf of relation. 
Consequently, the QoPy should be aggregated into 
QoPx for all the requests X sends after receiving 
request from Y , until X gets the result and responds 
Y . The 'on behalf of relation between X and Y 
ends when X responds Y . It also can, however, be 
interrupted before X responding Y . The following 
protocols regulate such cases. 

• Protocol 2: An 'X on behalf of Y' relation is interrupted 
by another 'X on behalf of Z' relation if Z makes request 
between X receiving request from Y and X responding 
Y. 

• Protocol 3: An 'X on behalf of Y' relation interrupted by 
another request from Z can be resumed after X responds 
Z, if X receives a response from a partner P, who was 
called by X 'on behalf of Y'. This means that the 'on 
behalf of relation can be nested. For example, with 
following request-response sequence (i.e. service call 
tuple list in formula [TOl l, we can say the 'on behalf 
of relation between X and Y is restored after 'X 
responds Z' (step 5), by the interaction where 'P 
responds X' , as 'P' is a partner that X has requested 
on behalf of Y . 

<rl,y ^X,A,i > 

<t2,X^P,A,2 > 

< t3, Z ^ X, A,3 > 

<T4,X^g,A,4,Ao4> (10) 

< t5, Z ^ X, Ao3 > 
<t6,X^P,Ao2> 

<T7,r^x,A„i> 

These are 'basic' protocols because they handle the 
most simple cases in service composition. When dealing 
with real-world complex business federations, more in- 
formation concerning the business process and partner 
functionalities should be taken into consideration. But 
the basic reasoning process remains in accordance with 
those described in these protocols. 

In the followings we discuss the employment of 'asset- 
based' and 'request-based' methods for context slicing. 
For this, we firstly give an overview of sub-context 
developments that can occur in a collaborative business 
process. 

3.5 Context development 

During each step (partner interaction) of the business 
process, different types of sub-context development are 
caused by the partners service calls: 



• Create: The creation of a new sub-context is always 
based on a independent QoP or RoP from a partner. 
In other words, if the partner provides an asset 
which is not aggregated with other assets in current 
step, a new sub-context consisting of this asset and 
the corresponding RoP is created. Analogously, if 
the partner is calling others 'on its own behalf (i.e. 
not because it is doing so for responding another 
'former' requestor) a new sub-context consisting of 
its QoP should be created. 

• Update: On the contrary, updating an existing sub- 
context happens if the partner's asset has data 
dependency (according to discussions in section 
13.31 1 with the assets belonging to an existing sub- 
context, or if this partners' assets are merged with 
existing assets. It also happens when the partner 
is requesting assets on behalf of other 'former' 
requestor, that is, it's QoP and the QoP of the former 
requestor should be 'transmitted' to the requested 
party. Therefore the QoPs are in the same sub- 
context. 

> Merge: Merging sub-contexts is a special kind of 
update operation. It happens when two existing as- 
sets in two sub-contexts merge, or when the request 
sand by a partner is on behalf of several former 
requestors from different sub-contexts. In the later 
case, the different sub-contexts are corelated by the 
asset value in the responding message. 

• Split: While 'splitting' a sub-context, several new 
sub-contexts are created. They all 'inherit' the assets 
and policies of the previous context. Context split- 
ting can be caused by three types of interactions: 

- a party sends copies of the same asset to several 
partners and the copies are developed differ- 
ently; 

- a party sends copies of the same request to 
several partners at the same time; 

- the business process has a control structure 
defining parallel activities. 

• End: Ending a sub-context occurs when it is merged, 
split or when the whole business process ends. 

3.6 Pre-processing and on-the-fly processing 

In context slicing, pre-processing refers to the circum- 
stances where a pre-defined business process (e.g. WS- 
BPEL script) is analyzed before the execution, to see 
whether it can be carried out, w.r.t. partners' security 
profile-request satisfiability. This can be done with the 
'asset-based' slicing method, given the policies and at- 
tributes of partners. 

In 'on-the-fly' processing, partners' RoPs and QoPs 
must be aggregated as soon as they join the collaboration 
context, in order to find out conflicts more timingly This 
requires using both 'asset-based slicing' and 'request- 
based slicing'. 

For 'use case 1', on-the-fly slicing strategy first builds 
the QoP tuples (see formula |9) from the start of the busi- 
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ness process, using 'request-based' slicing. Then from 
step 't3', RoP tuples are built (see formula [8|, using 
'asset-based' slicing. 

The decided RoP aggregation relations and QoP ag- 
gregation relations are used to generate the CSPs of each 
sub-context. When a new partner joins the collaboration 
context, it is allocated to a sub-context according to 
whether it's an asset provider or consumer (or both). 
Then it's policies are aggregated to the CSP of that sub- 
context. 

Next section gives a more featured illustration of the 
context slicing method based on a full-fledged collabo- 
rative context use case. 

4 Slicing a complex context 

This section demonstrates the context slicing method 
with a more comprehensive use case (see figure HJ. First, 
we briefly introduce the business process of this use 
case. Then, the corresponding 'Service Call Graph' and 
'service call tuple list' are described, before the 'on-the- 
fly' slicing process is discussed. Policies and CSPs of this 
use case are omitted for simplicity (can be found in (221). 
Use case 2: This use case is a collaborative busi- 
ness process for price inquiry. The tourism association 
'Eighty days around the World' (E) inquires 'Alice fan- 
tasy tourism' (A) for the total price and arrangement 
of 'Cote d'Azur and the Mediterranean package tour' 
for 50 persons. 'A' inquires 'Beausoleil tourist office' for 
fete information. Then 'A' produces the 'coach tour' ar- 
rangement information. It further inquires 'Cote d'Azur 
airline' (C) for travel arrangement (including air trans- 
port and accommodation); 'David cruise line' (D) for 
cruise arrangement; 'Friend-arm' (F) for assurance. 'C 
provides the arrangement of 'airline' and inquires three 
hotels 'Generous' (G), 'Hospitable' (H) and 'ldear(I) for 
room arrangements. 

4.1 Collaborative business process 

The main business process (denoted as 'CBP') comprises 
9 steps and two sub-process ('SBPC and 'SBPT'), as 
shown in figure S) 

The descriptions of the steps in CBP are as follows: 

• step 1: 'E' sends 'tourists info' (o) to 'A' to query for 
'total price and arrangement'. 

• step SBPC: 'A' initiates a sub-process 'SBPC to to 
inquiry the 'fete' (/) information. 

• step 2: It's composed of three concurrent sub-steps: 

- step 2.1: 'A' sends o and / to 'C to ask for 
'travel' information {v). It is followed (indirectly, 
there is a sub-process 'SBPT' between them) by 
two sub-steps: 

* SBPT 'C initiates a sub-process 'SBPT' to 
compose v. 

* step 3.1: 'C sends v to 'A'. 

- step 2.2: 'A' sends o to 'D' to query for 'cruise' 
information (u). It is followed by a step: 




SBPC 



~^ — > ( Step i 
(b) 



Step ii j 



[stepa.l)-^Stepb. 



r SBPT J >rstep a.2l ^TstepcJ 




(c) 

Fig. 4. Collaborative business process example: (a)CBP; 
(b)SBPC; (c)SBPT. 



* step 3.2: 'D' sends u to 'A'. 

- step 2.3: 'A' provides 'coach tour' irtformation 
(fc). 

• step 4: 'A' combines v, u, k and o to 'arrangement' 
information (r). 

• step 5: 'A' sends r to 'F' to query for 'assurance' 
information (n). 

• step 6: 'F' sends n to 'A'. 

• step 7: 'A' combines all the information to 'total 
price and arrangement' (t). 

. step 8: 'A' sends the t to 'E'. 

• step 9: 'E' processes t. 
The steps in SBPC are: 

• step i: 'A' queries 'B' for /. 
. step ii: 'B' sends / to 'A'. 
The steps in SBPT are: 

• step a: It consists in three concurrent steps initiated 
by 'C: 

- step a.l: 'C sends o to 'G' to ask for 'room' 
information (m). It is followed by: 

* step b.l: 'G' sends mg information to 'C. 

- step a.2: policy negotiation shows that the 
QoPh does not satisfy RoPe', 'C ceases calling 
the service of 'H'. 

- step a.3: policy negotiation shows that the QoPe 
does not satisfy RoPj; 'I' refuses to work with 
'C, because 'C is requesting 'on behalf of E. 

• step c: 'C combines 'airline' (1) information with 
'mc' to produce (v). 

In the following sections, we build the Service Call Di- 
agram (SCG) and discuss the sub-context slicing process. 
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4.2 Service Call Graph 

The service call diagram (figure |5| shows the partner 
interaction during these steps. 




4.3 On-the-fly slicing 

The business process starts with E's request, which leads 
to the creation of two sub-context. First, a QoP aggrega- 
tion starts from the QoPe- Second, a RoP aggregation 
starts from RoPe, as the request carries the 'tourist 
information' (o). 

4.3. 1 QoP aggregation 

Firstly, we track the QoP aggregation process. By step 1, 
QoPe leads to the creation of a sub-context: 



7(tr 
9 TO 6(„)5(; 



<QEA,lA(t>)AQoPE),Tl> 



(12) 




Fig. 5. SCG of the collaborative business process. 
Meanings of eiements are: 

. Green lines represent data-excliange messages 
whicii carries assets, wliere 

- Solid green lines (1, i, 2. 1, a. 1 b. 1, c, 3. 1, 2.2, 3.2, 
4, 5, 6, 7, 8, 9) represent the output messages that 
have used information from the input messages. 

- Dashed green lines (ii) represent the output mes- 
sages that don't include information from the in- 
put. 

• Solid Blue lines (a.2, b.2, a.3, b.3) represent control 

messages which doesn't carry assets. 
. Dashed blue lines represent the interaction that failed, 

due to negative result of policy negotiation. 
. Each green line is attached with the asset it carries. 

The list of service call tuple is as in formula lfTT) l: 

<t1,E ^A,{o) > 

d 



This sub-context splits as 'A' calls 'B', 'C, 'D' and 'F' 
separately. Thus we have 4 parallel sub-contexts created 
(see figure |6). 




Fig. 6. QoP aggregation, (a) E, A, B (b) E, A, C (c) E, A, 
F(d)EA,D 

They are presented by the following sub-context de- 
velopment tuples: 



<Ti+M,A^^B,(o),(/),^> 



< Qab, 1, (Qea-I), {QoPe,QoPa), Ti > 

< Qac,1,{Qea-1),{QoPe,QoPa),t2.1 > 

< Qad, 1, (Qba.1), {QoPe, QoPa),t2.2 > 

< QafA,{Qea-1)AQoPe,QoPa),t5 > 



(13) 



<t2.1,A^C,{o) > 



<Ta.l + b.l,C 

<Ta.2 + b.2,C 

<Ta.3 + b.3,C 

<Tc, C <-^ C, (mc, 0; (v) > 
d 



f 



GAo),{mG) > 



The sub-context QoPc-l further splits into 3 three new 
sub-contexts, as 'C calls 'G', 'H' and T for irtformation 
(see figure 0. 



<t2.2 + 3.2,A 

d 



C, (v) > 

d 



<t3.1,A 

D,{o),{u)> 
<t4, a <-^ A, (u, u, k), (r) > 



(11) 




<t5 + 6,A 



F, (r), (n) > 



<T7,A^^A,(r,n),(t)> 
<tS,E ^ A,{t) > 

d 



<t9,E 



E, (t) > 



Fig. 7. Details of QoP aggregation along 'E, A, C 



< QcGAAQAC-l),{QoPE,QoPA,QoPc),TaA > 

< QcH, 1, {QacA), {QoPE,QoPA,QoPc),Ta.2 > (14) 

< Qci, 1, (Qac-I), {QoPe, QoPa, QoPc),Ta.3 > 
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Set that QoPe doesn't satisfy RoPh and RoPj, This 
list of sub-context development tuples help us to find out 
this right after 'H' or T' is called. Otherwise, if using only 
RoP aggregation, we will find out that QoPe doesn't 
meet RoPj only at 'step 8', when the artifacts consisting 
asset from 'H' or '1' are send to 'E'. 

In short, the QoP aggregation 'transmits' the up- 
stream requesters' QoPs along the business process, so 
policies which do not match can be found in time. 
However, QoP aggregation isn't sufficient. As E's request 
carries o, any downstream partners receiving the request 
should fulfill RoPe- 

4.3.2 RoP aggregation 

We start to track RoP aggregation process from step 1, 
when 'E' send its request carrying o: 



<i?£A,l,(0),(o),(i?oP£),Tl> 



By 'step ii', as B's response / doesn't contain o, there 
is no asset aggregation between 'B' and others in this 
step. Therefore, a new sub-context is created. 



< RBA,l,{REA-l),{I),{RoPB),Tii > 



(16) 



However, these two sub-contexts should merge, as 'A' 
aggregates / and o before step 2.1 and 2.2. 

<Rea,'2, {Rea-1, Rba-1)Ao, f)ARoPE, RoPB),Tii > 

(17) 

This sub-contexts are succeeded by two different sub- 
contexts, as 'A' calls 'C and 'D' in parallel. 

• After 'A' calling 'C, 'C in turn calls 'G' and get 
mg. Then, 'C aggregate ma with I to get v. Thus 
we have the sub-context tuples: 



< Rgc, 1,{Rea.'2), (tog), 

{RoPE,RoPB,RoPG),Tb.l > 

< RGC,HRGC-l),(rnG,l), 

{RoPe , RoPb , RoPg , RoPc ),TC> 
With 'A' calling 'D' and getting u, we have: 
< Rda,IARea.2),{u), 

{RoPe , RoPb , RoPd ) , t3 . 2 > 



(18) 



(19) 



These two sub-contexts are merged when 'A' merges 
u, V and k into r. 



<Rda, 2, (i?GC-2, Rda-1), (w, w, k), 
{RoPe , RoPb , RoPg , RoPc , RoPd , RoP a ) , t4 > 



Now 'A' calls 'F' with asset r and the aggregated RoP 
of 'E', 'B', 'G', 'C', 'D' and 'A'. Set that QoPp fulfills the 
aggregated RoP, 'F' will join the context, providing asset 
n. Therefore the sub-context Rda-"^ get updated. 



< Rda, URda-2), (n), {RoPe, RoPb, RoPg, 
RoPc , RoPd , RoP a , RoPf ) , t6 > 
Then 'A' merges n with r into t. 



(21) 



<RDA,4,{RDA.3),{n,r), {RoPe, RoPb, RoPg, 
RoPc, RoPd, RoP a, RoPp), t1 > 



(22) 



In step 8 the aggregated RoP in sub-context Rda-4^ 
(formula l22ll is used to exam QoPe- 

The on-the-fly strategy analyze the business process 
to produce QoP and RoP aggregations. QoP aggregation 
allows transmitting former requesters' security attributes 
down-stream, to match RoPs in time. RoP aggrega- 
tion propagates former providers' security requirements 
down-stream, to ensure no leakage of the protected 
information to unauthorized consumer. 

5 Implementation 



(15) 5.1 'Context manager' component 



Implementation involves a 'context manager' service 
(see figure |8), which tracks the assets derivation to 
decide policy aggregation relations and RoP-QoP ne- 
gotiation relations among partners. Such information is 
sent to the policy engine we developed in former work 
[!25|, which includes a Policy Decision Point (standard 
XACML PDP, as our policy model can be implemented 
with XACML) for negotiation and a Policy Gathering 
Point for policy aggregation. 



Orchestration 
Engine A 




Monitor 
Service 



Provenance 'i—N Policy 
A"- Indiactor Asse 



12 

12 iZ_ 



Log Service 



^ 



-Policy Engine- 



\7 



PGP 



PDP 



(20) Fig. 8. Components of context manager 



Our context manager cooperates with the business 
engine to get the business process description encoded 
with WS-BPEL, for 'pre-processing' it before the 'or- 
chestration engine' starts business session. Major steps 
during the processing are: 

• step 1: The 'context analyzer' loads a business pro- 
cess defined with WS-BPEL and fetches the WSDL 
files of the business partners defined in the WS- 
BPEL. 
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• step 2: It uses 'asset-based' slicing method to pro- 
ceed sub-contexts partition and allocates assets to 
them, according to the assets merging/ inheriting 
relations. The 'provenance indicator' data records 
the sub-context development information. 

• step 3: For each 'sub context', the 'policies assem- 
bler' fetches the RoP and QoP policies of all part- 
ners, indicated by their WSDLs. It parses the QoPs 
to complete the requests. Then it sends requests and 
RoPs to the 'Negotiation and Aggregation' engine 
('PDP' for negotiation, 'PGP' for aggregation. 

• step 4: If the negotiation and aggregation results 
for all the 'sub contexts' are positive, the 'context 
manager' will call the 'orchestration engine' to start 
the business process. 

The analyzing algorithm is organized depending on 
the '< activities >' elements in WS-BPEL scripts, due 
to their impacts on sub-context development. Basically, 
they can be differentiated into 4 categories: 

• category 1: The activities that lead to information 
exchanges between partners, including < receive >, 

< reply >, < invoke >, < assign > and < exit >. 
This kind of activities can only result in the cre- 
ate/update/merge/end of context. 

• category 2: The 'control' activities that lead to con- 
text split, including: < sequence >; < flow > 
with 'parallel — yes' factor; < forEach > with 
'parallel — yes' factor; < if > with different 
activities in its branches. 

• category 3: The 'control' activities that do not lead 
to context split, including < pick >, < scope >, < 
while > and < repeatUntil >. But their children 
activities should be examined. 

• category 4: The activities that are irrelevant to con- 
text slicing, including < throw >, < wait >, < 
empty >, < compensate >, < compensates cope >, 

< rethrow >, < validate >, < extension Activity >. 

The context slicing process is carried out by two meth- 
ods. Method 'coordinator' (see algorithm [l]l locates the 
process starting point, i.e. a '< receive >', '< pick >' or 
'< onEvent >' activity that has a ' createlnstance factor, 
and creates the first context. Then it gets all the following 
activities and sends them to the 'analyze' method for 
tracking asset aggregations. 

Method 'analyze' (see algorithm |2]l deals with each 
activity according to its impact on context development. 
For activities of category 1, it calls a method 'develop' 
with ' slicer ~ update For activities of category '2', it 
splits {slicer = split) the context and examines the chil- 
dren activities. For activities of category '3', it examines 
the children activities. 

The method 'develop' updates the context list accord- 
ing to the 'sheer' factor. It creates a new 'context' if 
slicer =' split' , updates the version of an existing context 
if slicer =' update' . 



Algorithm 1 method 'coordinator' 



Require: 

The business process defined with WS-BPEL 
Ensure: 

An 'assembler' Object, which comprises the context 
slicing information 
1: Locate the starting activity of business process; 
2: Create the first 'asset' object according to the starting 

activity; 
3: Create the first 'context' object with the first 'asset' 

object, the 'variable and 'step information; 
4: Create the list of 'context' , which consists only the 
current context; 

Set the value of 'slicer' to update; 
for Each activity that follows starting activity do 
Call method 'analyze' with the activity, the 'slicer' 
and the list of context; 
8: Get the updated list of context; 
9: end for 

10: create 'assembler' object with the list of context; 
11: Enrich the context in the list with 'RoPs' and 'QoPs'; 

12: Output the configuration file with information in the 
list of context; 



5.2 Performance testing 

This section analyzes the performance of the 'Context 
Slicing' component, based on experiment with the five 
'Sample Processes' taken from the WS-BPEL2.0 specifica- 
tion [17J ('initial sample' and other 4 samples in section 
'15 Examples'). 

5.2. 1 Testing witti 'TPTP' 

Tables iQ) and 10 show the TPTP profiling results of 
'execution time' analysis and 'memory consumption' 
analysis separately. They are both based on running the 
'initial sample'. 



Package 


Base Time 
(ms) 


Average 
Time (ms) 


Cumulative 
Time (ms) 


Engine 


1.93 


1.93 


100 


I/O 


76.31 


38.15 


76.31 


Analyzer 


21.13 


0.17 


98.07 


Context 


0.44 


0.01 


0.44 


PartnerLink 


0.09 


0.01 


0.09 


Variable 


0.10 


0.01 


0.10 



TABLE 1 
Time percentage of components' execution 



As shown in table l[T]l, the I/O operation (the method 
'getJdomDoc') takes 76% of the total time. The analysis 
process itself only takes 24% the total time. As the file 
size of a BPEL document is usually very small, the I/O 
time doesn't change much with different BPEL files. 
Therefore, we can conclude that the algorithm scales well 
with complex (and long) BPEL processes. 
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Algorithm 2 method 'analyze' 



Require: 

A list of the Indicator object, sheer and current 
activity 
Ensure: 

An updated list of the Indicator object, slieer 
1: if activity in 'category 1' then 
2: Call method 'develop' with this activity, the 

'context' list and slieer; 
3: else 

4: if {activity in 'category 2') then 
5: for Each child activity do 

Set slieer = split'; 

Call method 'analyze' with the activity, the 
list of context and slieer; 
8: end for 

9: end if 
10: else 

11: if {activity in 'category 3') then 
12: for Each child activity do 

13: Call method 'analyze' with the activity, the 

'context' list and slieer; 
14: end for 

15: end if 
16: end if 
17: Output the context list; 



Class 
name 


Live In- 
stance 


Active 
Size (byte) 


Total In- 
stance 


Total Size 
(byte) 


Analyzer 


1 


224 


1 


224 


Context 


16 


896 


16 


896 


PartnerLink 


4 


128 


4 


128 


Variable 


5 


160 


5 


160 



TABLE 2 
Memory consumption of components' execution 



As shown in table (|2j, the memory consumption of the 
context slicing method is insignificant. The total size of 
memory consumption by all the instances is 1440 bytes. 
Therefore, its impact is trivial when deployed with an 
orchestration service. 

5.2.2 Deployment testing 

Figure Q shows the performance testing results, in 
terms of execution time for processing the 5 sample WS- 
BPEL processes. The two environments are: 

. 'Timel': 'Intel T7250 (Dual Core 2.0 GHz)' CPU and 

'3.49G' RAM. 
. 'Time2': 'Intel T2330 (Dual Core 1.6 GHz)' CPU and 

'2.00G' RAM. 

We can see from figure (|9]l that, first, although the 
business processes are different in length and complexity 
(see table|3]for comparison), the processing time for them 
only varies slightly. Second, the performance changes on 
different environments are evident. 



250 



S 200 



150 



S 100 



3 50 




intial example example 1 example 2 example 3 example 4 
Cases 

Fig. 9. Performance of deployment on different environ- 
ments 
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Detail information of the 5 processes is shown in table 



Meanings of column names are: 

• The column 'partnerLink' describes the number of 
'partnerLink' element in each BPEL file, 

• 'variable' the number of 'variable' element, 

• 'basic-activity' the total number of activities that in- 
cur partner interaction, i.e. 'receive', 'invoke', 'copy' 
'reply' and 'assign'. 



Examples 


Timel 
(ms) 


Time2 
(ms) 


partn- 
erLink 


Varia- 
bles 


Basic 

activity 


Initial 


156 


250 


4 


5 


10 


Examplel 


140 


218 


1 


3 


9 


Example2 


156 


242 


5 


7 


18 


Example3 


140 


211 


3 


3 


5 


Example4 


156 


234 


3 


6 


14 



TABLE 3 
Detail information of the sample BPEL processes 

We can see from table Q that the 'Initial example' 
and 'Example2' are more complex BPEL processes. Cor- 
respondingly, their processing time (show^n in figure |9ll 
are longer. 

6 Conclusion and future work 

Originator Control (ORCON) requires downstream con- 
sumers to fulfill the originator's requirements, therefore 
providing full lifecycle protection for assets (i.e. service 
and information) throughout the whole collaborative 
context. It ensures that the assets transmission, consump- 
tion and propagation are always in the scope defined 
with providers policies. 

Based on analyzing the characteristics of collaborative 
business process, this paper describes a originator usage 
control method fitting to inter-enterprise level business 
federation. We propose a 'Service Call Graph (SCG)' and 
a corresponding data structure 'service call tuple', based 
on extending the System Dependency Graph (SDG), to 
capture 'asset aggregation (and derivation)' in a collab- 
orative business process. A 'context slicing' operation 
can be made based on the 'SCG', to categorize partners 
that have direct and indirect assets exchange relations to 
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the same 'sub-contexts'. Security policy negotiation and 
aggregation done in the scope of each sub-context can 
ensure originator control principle. A detail discussion 
is given on the rational of our method, facilitated by two 
sample use cases. Basically, 'data dependency' between 
partners incurs assets (and RoP policies) aggregation, 
whereas 'control dependency' between partners leads 
to the 'on behalf of relation and QoP aggregation. 
According to data dependency, 'asset-based' slicing is 
sufficient for 'pre-processing' a business process script 
(e,g. WS-BPEL script). But for 'on-the-fly processing' a 
business federation (e.g. dynamic service composition), 
both 'request-based' (due to control dependency) and 
'asset-based' slicing should be used. Implementation 
works consolidate a 'context management' service, pay- 
ing particular attention to the analysis of BPEL-defined 
business processes. Impacts on the analysis algorithms 
from different types of 'activity' defined in WS-BPEL 2.0 
specification are discussed. Performance testing results, 
based on the 'sample business processes' that come with 
the 'WS-BPEL 2.0' specification, are presented. Future 
work involves, firstly, the enrichment of context man- 
ager functionality with 'on-the-fly' analysis capability, 
by managing djrnamic service composition. This can 
be done based on 'PEtALS ESB' system, by extending 
its service management functionality. Following work 
includes the development of components for enforcing 
originators usage control policies. 
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